-
-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(passport): custom domain #2330
Conversation
417fe41
to
4138f38
Compare
Should the cookie |
`Completed HTTP handler for ${reqURL.pathname}/${reqURL.searchParams}`, | ||
newTraceSpan.toString() | ||
) | ||
const app = await starbaseClient.getAppPublicProps.query({ clientId }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's a thought, not sure if we should do this but worth putting out there: if we're to set a acceptedDomain metadata prop when we store the clientId on there, we'd be able to check both things without having to call starbase at all. I'm thinking the headers are injected more quickly in the request compared to the roundtrip time of passport->starbase->DO and back. Headers would get bigger is one downside, and we don't know the consistency/reliability characteristics of the metadata store. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do that but it'd be a redundant check. The request host and the host in the metadata would be the same assuming Cloudflare wouldn't make a mistake. I think it is okay to try it out during beta.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other condition checked is the status of the domain which depends on the validations. It can be ignored only as long as Cloudflare passes traffic over the custom hostname.
apps/passport/wrangler.toml
Outdated
@@ -54,10 +55,11 @@ services = [ | |||
] | |||
|
|||
[env.dev.vars] | |||
HOST = "passport-dev.rollup.id" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe call this DEFAULT_HOST or PASSPORT_HOST or something, for clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
I think some of the callback redirects won't work with Strict. IIRC that's the reason why kept it as it currently is for non-custom domain passport. |
dc0a68c
to
c58de35
Compare
I found out that a request to |
e589e37
to
322b887
Compare
322b887
to
93be7a7
Compare
Pending a test on the development environment. |
844725e
to
56974f5
Compare
56974f5
to
dcd9c23
Compare
dcd9c23
to
6483f8e
Compare
Description
Introduces a utility function named
getCookieDomain
. If the request host isnot matching the defined
HOST
then the request will be checked for a customdomain if the request has
clientId
in the host metadata.The server entry point implements a similar process to check the custom domain
status at the beginning of the request lifecycle.
Related Issues
Testing
Manual
Create a custom domain in the console for a published application
Do the validation steps and finally create the CNAME record
Visit passport using the custom domain and login
Checklist